with the addressee's new public key." The Examiner has cited Smith as showing these 
items. However, Smith merely shows automatically generating a new recipient public key 
when none is found. "In the event that the certificate authority returns no certificate, the 
Delivery Server dynamically generates a new certificate for the recipient." The claims 
require that this generation must be done in "response" to an acknowledgement from the 
recipient. Smith does not show this. Nowhere is it taught that the encryption depends on a 
response from the recipient. 

Additionally, an "escrow" key is first applied to the document. This is not shown by 
Smith. Thirdly, the escrow key is removed prior to applying the new recipient key 
"decrypting the package decryption key; encrypting the package decryption key with the 
addressee's new public key." If, as the Examiner presumes, the new recipient's key and 
the escrow key were the same, there would be no reason to unencrypt and reencrypt 
the document with the exact same key. The escrow key is not the recipient's key, the 
recipient's key is clearly the key assigned to the recipient in Smith. For the Examiner to 
read both elements as the separate elements of the escrow key and the recipient's 
public key is impermissible, as to do so would improperly read a "double inclusion" into 
the claim. Dorenbos does not show an escrow key. The keys are well described in the 
specification as being separate elements. 

Dorenbos merely shows the package encryption and the public key encryption, 
"The encryption server 101 the encrypts the user's ID along with the first-stage 
encrypted message by encrypting with the public key of the first recipient." Nowhere is 
a package key and an escrow key. merely with different recipients keys. Smith merely 
duplicates the teaching of a recipient's public key. For at least these reasons, claim 1 is 
allowable over the art of record. 
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Claim 1 1 analogously requires a package key encrypted with an escrow key and 
a transmission module for decrypting the package key and encrypting with the 
recipient's public key after registration. This is not shown and claim 1 1 should be 
allowable for at least this reason. 

Claim 18 also requires a computer code which encrypts a package decryption 
key with a escrow key and, upon receipt of the recipient's public key removes the 
escrow encryption and applies the recipient's public encryption. This is not shown and 
claim 18 should be allowed over the art of record. 

Claims 2, 12 and 19 also require that the escrow key is used "n response to not 
finding (or failing to find) a public key. As described above, Smith merely shows 
generating a new recipient public key when the public key is not found. For the reasons 
above, Smith does not show both the escrow and recipient keys. The Examiner's 
attempt to read the public key as both the escrow key and the recipient's key is 
impermissible and contrary to the plain meaning of the claims. Additionally, claim 2 
requires that the escrow key be sent back to the sender. This is done so that the sender 
does not have to wait for the recipient's new key to be generated. Smith teaches away 
from this concept by generating a new recipient key instead. 

The remaining claims should be allowable for at least the reason that they 
depend from an allowable claim and for the additional recitations found in those claims. 
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Formal Drawings 

Formal drawings were filed with the application on 6/14/2001. A review of the 
Office Action has failed to uncover whether the drawings were accepted by the Official 
Draftsman or whether a Form 948 rejection was issued by the Official Draftsman. An 
indication of the status of the drawings is respectfully requested with the next 
communication from the Patent Office. 
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Summary 



Applicants have made a diligent and bona fide effort to answer each and every 
ground for rejection or objection to the specification including the claims and to place 
the application in condition for final disposition. Reconsideration and further 
examination is respectfully requested, and for the foregoing reasons, Applicant 
respectfully submits that this application is in condition to be passed to issue and such 
action is earnestly solicited. However, should there remain unresolved issues that 
require adverse action, it is respectfully requested that the Examiner telephone Robert 
N. Blackmon, Applicants' Attorney at 703-684-5633 to satisfactorily conclude the 
prosecution of this application. 



Dated: June 30, 2006 



Respectfully submitted. 



Merek, Blackmon & Voorhees, LLC 
673 S. Washington St. 
Alexandria, Virginia 22314 
Tel. 703-684-5633 
Fax. 703-684-5637 
E-mail: RNB@MBV-IP.com 
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